Three related UI-renderer changes, all bound to the "Creators Success" signal that UI must be rebuilt/tested separately for desktop and mobile. The virtual-screen half is inherited from the reverted #1444.

1. devicePixelRatio out of UI layout

The UI scale factor is now the contain-fit of the design resolution inside the canvas, and nothing else:

Math.min(canvasWidth / virtualWidth, canvasHeight / virtualHeight)

scaleOnDim drops it too, so 1vw is 1% of the canvas width and 1vh 1% of its height, exactly as in CSS. devicePixelRatio stays on UiCanvasInformation and on ScaleContext as an informational density hint — the "pick a 1x/2x/3x asset" signal — which is the same role it has in CSS and React Native, where it is exposed but never enters layout.

2. Default virtual screen

How setUiRenderer / addUiRenderer resolve the virtual screen used for UI scaling:

• No virtual size provided → platform default: 1600x720 on mobile, 1920x1080 otherwise. Previously no scaling was applied at all.
• Invalid size provided (values ≤ 0) → virtual screen disabled: no UI scaling, and any previously applied scale factor is released (matches the old no-options behavior).
• Valid 16:9 size on mobile (1920x1080, 1280x720, …) → overridden to 1600x720, since phone screens are much wider than 16:9 and a 16:9 canvas would letterbox the UI. A console.log notifies the creator once per provided size, not every tick.
• Non-16:9 sizes on mobile and any valid size on desktop/web are respected as-is.

The virtual size stays a single scene-wide value: main renderer options win, else the first additional renderer that passed dimensions, else the platform default. Options carrying no dimensions (e.g. only a screenInset) are skipped, so they don't read as a provided-but-invalid size. Defaults apply to scenes that only ever call addUiRenderer() too.

Resolution runs every tick in UiScaleSystem, so it reacts correctly when async platform detection resolves to mobile a few frames after scene start. The virtual screen only applies while a renderer is registered; with no UI at all the scale factor is released.

3. Default screen inset area

Adds an optional screenInset to UiRendererOptions selecting the screen area a renderer's UI is positioned in:

• 'device' (default) → the device safe area (excludes notch, status bar, rounded corners), from UiCanvasInformation.screenInsetArea. Zero on desktop, so a no-op there.
• 'interactable' → the area free of the Explorer's native HUD (minimap, chat, …), from UiCanvasInformation.interactableArea.
• 'none' → the whole screen, 0,0 at its top-left corner; no wrapper entity is added.

'device' is the default because drawing under a notch, a status bar or a rounded corner should be something a creator opts into, not the out-of-the-box behavior. Each renderer honors its own value, so the main UI and additional renderers can use different insets simultaneously.

Inset values are reported by the renderer in canvas pixels, and raw pixel props are multiplied by the UI scale factor when parsed — so ScreenInsetArea / InteractableArea now pre-divide the insets by the scale factor (compensateInsetForUiScale), keeping the values sent to the renderer in canvas pixels at any virtual screen size.

How

• @dcl/react-ecs cannot depend on ~system/Runtime (and depending on @dcl/sdk would be circular), so a new src/platform.ts exposes an injectable isMobile provider defaulting to non-mobile.
• @dcl/sdk/react-ecs wires that provider to @dcl/sdk's existing isMobile() helper at module load.
• system.ts resolves the active virtual size, applies the default / disable / mobile-override rules, and wraps each renderer's component in its selected inset area.

API changes

export type UiRendererOptions = {
  virtualWidth?: number   // now optional
  virtualHeight?: number  // now optional
  screenInset?: UiScreenInset  // defaults to 'device'
}

export type UiScreenInset = 'device' | 'interactable' | 'none'

Versioning

All three changes alter the rendered result of scene code that was not modified — a scene that passed no options gains a virtual screen, UI on mobile gains a device inset, and pixel sizes change on high-density screens. That argues for a minor bump (7.26.0) rather than the patch (7.25.1) that oddish currently computes off the latest tag.

Creator-facing note

A UI already wrapped in <ScreenInsetArea> now sits inside a renderer that is also insetting by default, applying the margin twice. Either drop the wrapper or pass screenInset: 'none'.

Tests

• virtual-size-defaults.spec.tsx — default / invalid / mobile-override resolution, including addUiRenderer-only scenes.
• ui-renderer-screen-inset.spec.tsx — per-renderer inset wrapping.
• interactable-area.spec.tsx / screen-inset-area.spec.tsx — inset scale compensation.
• virtual-scale-array.spec.tsx, transform.spec.tsx, label.spec.tsx, tree.spec.tsx, background.spec.tsx, button.spec.tsx, add-ui-renderer.spec.tsx — updated for the dpr-free scale factor and the default inset wrapper.
• ui.ts.crdt snapshot updated: now requires ~system/Runtime for platform detection, adds the inset wrapper entity, and the bundle grows 410.7k → 412.6k.